Spring+Hibernate is often called the most commonly used stack behind java web applications these days. While the today-JCP-approved Web Beans JSR would standardize a web stack combining JSF+EJB+JPA and many elements from JBoss Seam (excluding Spring), and EJB 3 now providing a simplified session bean framework with basic interception and dependency injection, Spring 2.0 now provides the complete EJB container contract for JPA, allowing JPA to be used under a Spring managed services layer (with all the AOP and DI richness of Spring) in any environment. Debates are already beginning about whether the next defacto stack will be EJB, Spring+Hibernate, or Spring + JPA.
Using JPA in standalone has been demonstrated on Tomcat and on Geronimo, but this method suffers some limitations, for example the a persistence context cannot be shared across Entity Managers in the same transaction automatically. By implementing the ejb container contract, Spring allows the injection of the persistence across components in the same transaction, as well as the ability to have components join transactions and also support for extended persistence context. Spring 2 thus allows the use of JPA with all the features supported within a container.
Mark Fisher recently demonstrated JPA with Spring in a standalone environment using the Toplink Essentials JPA reference implementation from Glassfish. Mark took a simple JPA domain model and showed now it could run in Spring:
Recently, Spring's project Pitchfork (which provides parts of the full EJB api's to WebLogic) was used to demonstrate deploying full EJB on Tomcat, although full EJB on Tomcat with Spring is not intended for production use, Rod Johnson mentioned that "the intent is not to write an EJB container." JBoss is also offering an embeddable EJB container that can run EJB 3 on Tomcat, with some limitations.
A huge debate errupted between Gavin King and various Spring folks last week about JBoss and EJB 3 vs. Spring "quasi-ejb container" (as Gavin put it). The Spring folks maintain that JPA is the main value of the new EJB spec and session beans are a poor subset of Spring in terms of dependency injection and AOP capabilities, and are pushing Spring+JPA. Gavin King responded saying that they are attempting to promote further Spring lock-in by pushing Spring instead of building "addons for EJB3 via the extension points provided by the spec."
2006 and 2007 will definitely see a lot of competition and innovation for the next defacto standard for transactional, persistent java web app development. Their appear to be three camps, Sun/JCP, JBoss, and Spring. Will the community rally around EJB or shrug it off and stick to Spring+JPA or Spring+Hibernate? When Web Beans finalizes, things will get even more interesting, and InfoQ will be here, to track the change and innovation that will be occuring at each step.
Using JPA in standalone has been demonstrated on Tomcat and on Geronimo, but this method suffers some limitations, for example the a persistence context cannot be shared across Entity Managers in the same transaction automatically. By implementing the ejb container contract, Spring allows the injection of the persistence across components in the same transaction, as well as the ability to have components join transactions and also support for extended persistence context. Spring 2 thus allows the use of JPA with all the features supported within a container.
Mark Fisher recently demonstrated JPA with Spring in a standalone environment using the Toplink Essentials JPA reference implementation from Glassfish. Mark took a simple JPA domain model and showed now it could run in Spring:
I am going to extend Spring’s JpaDaoSupport class. This provides a convenience method for retrieving the JpaTemplate. If you have used Spring with JDBC or other ORM technologies, then you will probably be quite familiar with this approach. It should be noted that use of the JpaDaoSupport is optional. It is possible to construct a JpaTemplate directly by simply providing the EntityManagerFactory to its constructor. In fact, the JpaTemplate itself is optional. If you do not wish to have the automatic translation of JPA exceptions into Spring’s runtime exception hierarchy, then you can avoid JpaTemplate altogether. In that case, you may still be interested in Spring’s EntityManagerFactoryUtils class which provides a convenient static method for obtaining the shared (and thus transactional) EntityManager.Spring 2.0 documentation has also been updated with a section showing how JPA is supported in the same way as Hibernate or TopLink. At Java One, Rod Johnson mentioned to InfoQ that Spring is putting a lot of effort into ensuring portability into JPA integration, the aim being to easily allow the swapping of JPA providers such as Hibernate, TopLink, OpenJPA, etc.
Recently, Spring's project Pitchfork (which provides parts of the full EJB api's to WebLogic) was used to demonstrate deploying full EJB on Tomcat, although full EJB on Tomcat with Spring is not intended for production use, Rod Johnson mentioned that "the intent is not to write an EJB container." JBoss is also offering an embeddable EJB container that can run EJB 3 on Tomcat, with some limitations.
A huge debate errupted between Gavin King and various Spring folks last week about JBoss and EJB 3 vs. Spring "quasi-ejb container" (as Gavin put it). The Spring folks maintain that JPA is the main value of the new EJB spec and session beans are a poor subset of Spring in terms of dependency injection and AOP capabilities, and are pushing Spring+JPA. Gavin King responded saying that they are attempting to promote further Spring lock-in by pushing Spring instead of building "addons for EJB3 via the extension points provided by the spec."
2006 and 2007 will definitely see a lot of competition and innovation for the next defacto standard for transactional, persistent java web app development. Their appear to be three camps, Sun/JCP, JBoss, and Spring. Will the community rally around EJB or shrug it off and stick to Spring+JPA or Spring+Hibernate? When Web Beans finalizes, things will get even more interesting, and InfoQ will be here, to track the change and innovation that will be occuring at each step.